suggestion: Clarify the meaning of "true cursors". Suggest using "offset-based cursors" vs "range-based cursors" to distinguish the approaches.

The term "true cursors" might be confusing to users. Using more descriptive terms like "offset-based cursors" and "range-based cursors" would improve clarity.

Suggested implementation:

It supports pagination through a Django `QuerySet` via range-based cursors.

`ListConnection` uses offset-based cursors (slicing) to achieve pagination, which can negatively affect performance for huge datasets,

issue (complexity): Consider refactoring the complex, nested logic in build_tuple_compare and apply_cursor_pagination into smaller, well-named helper functions to improve readability and maintainability by reducing nested code blocks and improving readability..

Consider splitting the complex, nested logic into smaller helper functions. For example, the loop in build_tuple_compare mixes comparator and equality handling with nested conditionals. You can extract the "compare" logic into a helper:

def _compare_field(descriptor: OrderingDescriptor, field_value: Any, before: bool) -> Q:
    value_expr = Value(field_value, output_field=descriptor.order_by.expression.output_field)
    comparator = descriptor.get_comparator(value_expr, before)
    eq = descriptor.get_eq(value_expr)
    if comparator is None:
        return eq
    return comparator | (eq & Q())

def build_tuple_compare(
    descriptors: list[OrderingDescriptor],
    cursor_values: list,
    before: bool,
) -> Q:
    comparators = [
        _compare_field(descriptor, value, before)
        for descriptor, value in zip(reversed(descriptors), reversed(cursor_values))
    ]
    # Combine comparators with an 'AND' chain
    current = Q()
    for comp in comparators:
        current &= comp
    return current

Similarly, consider isolating parts of the slicing logic in apply_cursor_pagination into a small helper. For example:

def _apply_slice(qs: QuerySet, slice_: slice, related_field_id: Optional[str]) -> QuerySet:
    if related_field_id:
        offset = slice_.start or 0
        return apply_window_pagination(qs, related_field_id=related_field_id, offset=offset, limit=slice_.stop - offset)
    return qs[slice_]

# Then in apply_cursor_pagination replace:
if slice_ is not None:
    qs = _apply_slice(qs, slice_, related_field_id)

This approach keeps all functionality intact while reducing nested code blocks and improving readability.

question: is this change safe? If I remember correctly, the reason we would do this was to mark a prefetch query as optimized, because that config there could be lost

Is that not an issue anymore with the changes here? I sincerely don't remember how it would be lost and even if we have a test that would break without this (hopefully we do)

From my understanding it is safe, yes. If I change is_optimized_by_prefetching to just return False then various tests fail, most importantly this one:

My understanding of why this code was written as it was before my change is as follows:

1. get_queryset_config was broken in that it never set the configuration on the QuerySet. This wasn't caught because
   1. There were no tests for it.
   2. If it fails, that is only catastrophic for is_optimized_by_prefetching. The other things in the QuerySet config can cause the optimizer to optimize a QuerySet twice or they can cause a type's get_queryset to be called twice. Both of these are usually idempotent so don't cause any issues except for wasted CPU cycles.
2. The above caused the get_queryset_config bug to never surface until is_optimized_by_prefetching was introduced and at that point the config disappearing was wrongly attributed to being related to prefetch_related when in reality get_queryset_config never worked.

question: Why do we have this?

We need to serialize the values of all order_by columns into the cursor, which is just a string. The fields could be of any type so we don't want to just str() them. Django model fields already have built-in serialization to and from strings, which Django uses for serializing and deserializing model instances (mainly for fixtures).

The API however is unfortunately somewhat clunky. Instead of Field.value_to_string(value) we get Field.value_to_string(obj) with obj being the model to look up the field on. So you could do something like

field_value_str = some_model_field.value_to_string(my_model_instance)

This works for fields which are present on the model, but users can order by arbitrary annotations:

qs.alias(name_up=Upper('name')).order_by('name_up')

Now we need to somehow turn the value of that annotation into a string via value_to_string - but there's no actual field for it. Hence we construct this AttrHelper and set the attribute that the field is looking for on it. This happens here:
https://github.com/diesieben07/strawberry-graphql-django/blob/39dcdd6e09aaf20c831707d6e01e4bfdacb24028/strawberry_django/relay_cursor.py#L179-L184

We can't use a plain object(), because you can't set arbitrary attributes on them.

Django's own ArrayField for PostgreSQL uses a similar technique:
https://github.com/django/django/blob/ab1b9cc1b38e8735979c817f42e8f54a5795c4f7/django/contrib/postgres/fields/array.py#L166-L167